fix: align community submission workflows with bug-assess label trigger#3046
Conversation
The add-community-extension and add-community-preset agentic workflows never ran for real submissions. Their issue templates auto-applied the `extension-submission`/`preset-submission` label at creation, which lands in the `opened` event (not `labeled`), and the external submitter fails the team-membership activation gate. Align both with the working bug-assess pattern: - Add `names: [extension-submission]` / `[preset-submission]` so a job-level condition gates activation on the specific label. - Add `github: min-integrity: none` to allow reading external user issues. - Remove the trigger label from the issue-template auto-labels so a maintainer applies it during triage — emitting a real `labeled` event from a team member, which passes activation. - Recompile lock files with gh aw v0.79.8. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
✅ Ready to approve
The trigger/label-flow changes are consistent with the established bug-assess workflow approach and the compiled lock files reflect the intended gating and min-integrity: none policy.
Note: this review does not count toward required approvals for merging.
Pull request overview
This PR fixes community submission agentic workflows so they actually run on real extension/preset submissions by aligning their trigger and permissions behavior with the existing bug-assess workflow pattern (maintainer-applied triage label + external-issue readability).
Changes:
- Add label gating (
names: [...]) andtools.github.min-integrity: noneto theadd-community-extensionandadd-community-presetagentic workflow sources. - Recompile both generated lock workflows with
gh awv0.79.8 so the compiled jobs enforce the label gate and the updated GitHub MCP guard policy. - Update the issue templates to stop auto-applying
extension-submission/preset-submission, ensuring the triggering label is applied during maintainer triage (emitting a reallabeledevent from a team member).
File summaries
| File | Description |
|---|---|
| .github/workflows/add-community-preset.md | Adds label gating and min-integrity: none so the preset submission workflow can read external issues and only proceeds for preset-submission. |
| .github/workflows/add-community-preset.lock.yml | Recompiled workflow implementing the label gate and updated guard/runtime behavior from gh aw v0.79.8. |
| .github/workflows/add-community-extension.md | Adds label gating and min-integrity: none so the extension submission workflow can read external issues and only proceeds for extension-submission. |
| .github/workflows/add-community-extension.lock.yml | Recompiled workflow implementing the label gate and updated guard/runtime behavior from gh aw v0.79.8. |
| .github/ISSUE_TEMPLATE/preset_submission.yml | Removes auto-applied preset-submission label so maintainers apply it during triage. |
| .github/ISSUE_TEMPLATE/extension_submission.yml | Removes auto-applied extension-submission label so maintainers apply it during triage. |
Copilot's findings
- Files reviewed: 6/6 changed files
- Comments generated: 0
Note
Your feedback helps us improve the quality of this feature.
Please use 👍 or 👎 to tell us whether this assessment is correct.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Problem
The
add-community-extensionandadd-community-presetagentic workflows never ran for real submissions, whilebug-assessworks fine.Root cause is a trigger-timing mismatch:
extension-submission/preset-submissionlabel at issue creation. Labels set by an issue template arrive inside theopenedevent payload — GitHub does not emit a separatelabeledevent for them. The workflows only subscribe tolabeled, so they never trigger.labeledevent did fire at creation, the actor is the external submitter, who lacksadmin/maintainer/write, so theis_team_memberactivation gate (GH_AW_REQUIRED_ROLES: admin,maintainer,write) blocks the run..mdalso lacked anames:label filter (so the compiled lock had no label gate at all), and the lock files were stale (v0.78.1/ info1.0.48).bug-assessavoids all of this: itsbug-assesslabel is maintainer-applied during triage, producing a reallabeledevent from a team member..github/workflows/catalog-assign.yml(a plain workflow handling the same label) already covers bothopenedandlabeled, which is what masked the gap.Fix — align with the
bug-assesspatternnames: [extension-submission]/[preset-submission], so a job-level condition gates activation on the specific label.github: min-integrity: noneto allow reading external user issues (the fixbug-assessreceived in fix(bug-assess): set min-integrity: none to allow reading external user issues #3030).["enhancement", "needs-triage"]) so a maintainer applies it during triage — emitting a reallabeledevent from a team member, which passes activation.gh awv0.79.8.New flow
enhancement,needs-triage.extension-submission/preset-submission.labeledevent fires bothcatalog-assign(already handleslabeled) and the agentic workflow, which now proceeds.No changes needed outside these files —
catalog-assign.ymlalready has alabeledbranch for these labels.